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Applicants appeal the outstanding Final Rejection of May 23, 2006, finally rejecting 
each of pending claims 1-30. 



I. REAL PARTY IN INTEREST 
The above-noted application is assigned to Ricoh Company, Ltd., which is the real 
party in interest, having a place of business at Tokyo, Japan. 



n. RELATED APPEALS AND INTERFERENCES 
Applicant and Applicant's representative are not aware of any related appeals or 



interferences that will directly effect or be directly affected by,OE,haying a bearing on the 
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Board's decision in the pending appeal. rtil482 
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III. STATUS OF CLAIMS 
Claims 1-30 are pending in this application and the rejection of each of Claims 1-30 is 
being appealed. 

No claims were cancelled or added during prosecution of this application. 

IV. STATUS OF AMENDMENTS 
A Request for Reconsideration was filed subsequent to the Final Rejection dated May 
23, 2006. Accordingly, all previously filed Amendments have been considered by the 
Examiner and are reflected in the attached claims. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 
The applicants of the present invention recognized that a problem exists in the current 
art in that until the present invention there was not a method and system for initializing a 
plurality of protocol objects associated with respective communication protocols (e.g., HTTP, 
SNMP, FTP) used to extract status information (e.g., print counts, toner levels) related to a 
monitored device (e.g., a printer or copier) communicatively coupled to a network. 

Accordingly, Claim 1 sets forth a method of initializing a plurality of protocol objects 
associated with respective communication protocols used to extract status information related 
to a monitored device communicatively coupled to a network. Claim 1 finds general support 
in Figures 27A-30 and paragraphs 167-178 in the specification. See, in particular, the 
flowchart of Figure 28. 

In particular, Claim 1 recites the step of selecting a communication protocol among 
the respective communication protocols, which finds support, e.g., in Figure 28 (step 602); 
and paragraph 171, p. 44 of the specification (obtaining a protocol object fi-om the vector 
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shown in Figure 27A, wherein each protocol object corresponds to a different communication 
protocol used to extract information from the monitored device). 

Further, Claim 1 recites the step of retrieving, from a first memory, information for 
accessing the device using the selected communication protocol, which finds support, e.g., in 
paragraph 172, p. 45, lines 22-32 (device is accessed using SNMP, FTP, or HTTP to get 
vendor name based on information stored in a database). 

Further, Claim 1 recites the step of accessing the device using the selected 
communication protocol and the information retrieved from the first memory to attempt to 
obtain vendor information related to the device , which finds support, e.g., in Figure 28 (step 
608); and paragraph 172, p. 45, lines 20-32 (monitored device is accessed using the protocol 
and information from the database). 

Further, Claim 1 recites the step of determining whether the vendor information was 
obtained from the device , which finds support, e.g., in Figure 28 (step 610); and paragraph 
171, sentence bridging pages 44 and 45 (check to see if vendor name was obtained). 

Further Claim 1 recites two steps that include preconditions. In particular. Claim 1 
recites the step of if the vendor inforrnation was obtained from the device, (1) obtaining, from 
a second memory, support information for extracting the status information using each of the 
respective communication protocols, and (2) storing the vendor information and the 
respective support information in each protocol object of the plurality of protocol objects, 
which finds support, e.g., in Figure 28 (step 612 from YES branch of step 610); and 
paragraph 171, p.45, lines 4-10 (protocol object is initialized with information for extracting 
status information from the monitored device). See also Figures 27B-27D. 

The other conditional step recited in Claim 1 is: if the vendor information was not 
obtained from the device, repeating the preceding steps xmtil the vendor information is 
obtained or until each commimication protocol of the respective communication protocols 
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has been selected, which finds support, e.g., in Figure 28 (No branch of step 610; step 604, 
which checks if all protocols have been tried). Note that the 602-610 loop exits at either step 
604 (no more protocols) or step 610 (vendor information obtained). See text on upper left 
side of Figure 28. 

Independent Claims 1 1 and 21 recite limitations analogous to the limitations recited in 
Claim 1. 

In particular, independent Claim 1 1 sets forth a system for initializing a plurality of 
protocol objects associated with respective communication protocols used to extract status 
information related to a monitored device communicatively coupled to a network, 
comprising: means for selecting a communication protocol among the respective 
communication protocols; means for retrieving, from a first memory, information for 
accessing the device using the selected communication protocol; means for accessing the 
device using the selected communication protocol and the information retrieved from the first 
memory to attempt to obtain vendor information related to the device; means for determining 
whether the vendor information was obtained from the device; means for obtaining, from a 
second memory, support information for extracting the status information using each of the 
respective communication protocols, if the means for determining determines that the vendor 
information was obtained from the device; and means for storing the vendor information and 
the respective support information in each protocol object of the plxu-ality of protocol objects, 
if the means for determining determines that the vendor information was obtained from the 
device. 

Independent Claim 21 is directed to a computer program product having a computer 
usable medium for initializing a plurality of protocol objects associated with respective 
communication protocols used to extract status information related to a monitored device 
communicatively coupled to a network, comprising: instructions for selecting a 
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communication protocol among the respective communication protocols; instructions for 
retrieving, from a first memory, information for accessing the device using the selected 
communication protocol; instructions for accessing the device using the selected 
communication protocol and the information retrieved from the first memory to attempt to 
obtain vendor information related to the device; instructions for determining whether the 
vendor information was obtained from the device; if the vendor information was obtained 
from the device, (1) instructions for obtaining, from a second memory, support information 
for extracting the status information using each of the respective communication protocols, 
and (2) instructions for storing the vendor information and the respective support information 
in each protocol object of the plurality of protocol objects; and if the vendor information was 
not obtained from the device, instructions for repeating the preceding instructions until the 
vendor information is obtained or until each communication protocol of the respective 
communication protocols has been selected. 

Claims 1 1 and 21 are generally supported by the system and computer components 
shown in Figures 1-3,8, and 9 and the discussion related thereto in the specification. See, 
e.g., the monitoring station 902 in Figure 9. Moreover, the functionality recited in Claims 1 1 
and 21 is supported as set forth above with respect to Claim 1 (e.g., in Figure 28). the general 
object-oriented architecture of the monitoring system is shown in Figures 10-18 and 23-26. 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 
The ground of rejection being appealed is as follows: 

whether the teachings of U.S. Patent Application Publication No. U.S. 2004/0088405 
to Aggarwal (hereinafter "the '405 application") in view of the teachings of U.S. Patent No. 
5,787,248 to Zupcsics et al. (hereinafter "the *248 patent") renders obvious the subject matter 
of Claims 1-30 under 35 U.S.C. § 103(a). 
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VIL ARGUMENT 

Claim 1 is directed to a method of initializing a plurality of protocol objects 
associated with respective communication protocols used to extract status information related 
to a monitored device communicatively coupled to a network, comprising: (1) selecting a 
communication protocol among the respective communication protocols; (2) retrieving, from 
a first memory, information for accessing the device using the selected communication 
protocol; (3) accessing the device using the selected conmiunication protocol and the 
information retrieved from the first memory to attempt to obtain vendor information related 
to the device; (4) determining whether the vendor information was obtained from the device; 
(5) if the vendor information was obtained from the device, obtaining from a second memory, 
support information for extracting the status information using each of the respective 
communication protocols, and storing the vendor information and the respective support 
information in each protocol object of the plurality of protocol objects; and (6) if the vendor 
information was not obtained from the device, repeating the proceeding steps until the vendor 
information is obtained or until each communication protocol of the respective 
communication protocols has been selected. 

Regarding the rejection of Claim 1 under 35 U.S.C. § 103, the Office Action asserts 
that the '405 application discloses everything in Claim 1 with the exception of the selecting 
step, and relies on the '248 patent to remedy that deficiency. 

The '405 application is directed to a fault and performance monitoring system using 
distributed data gathering and data storage. As shown in Fig. 4, the '405 application 
discloses a method of configuring devices on a network, associating the devices with a 
particular test, associating data gathering operations (DGEs) with the devices, and sending 
the performance configuration information to the respective data gathering operations 
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(DGEs). As shown in Fig. 6, after the DGEs are configured, the devices can be monitored by 
polling or by event triggering. Further, the *405 application discloses that "[p]ort and SNMP 
tests can be automatically 'discovered' by querying the device to see what services are 
running. The system can automatically detect disk partitions, volumes and their sizes so that 
the usage is normalized as a percentage."^ Further, the '405 application discloses that "when 
the auto-discovery for SNMP occurs, the target device database record may be updated with 
vendor and model information."^ 

However, Applicants respectfully submit that the '405 application fails to disclose the 
two conditional steps recited in Claim 1 . In particular, the '405 application fails to disclose 
that if the vendor information was obtained from the device , (1) obtaining from a second 
memory, support information for extracting the status information usirig each of the 
respective communication protocols, and (2) storing the vendor information and the 
respective support information in each protocol object of the plurality of protocol objects, as 
recited in Claim 1. Regarding vendor information, the '405 application discloses that the 
target device database record may be updated with vendor and model information when the 
auto-discovery for SNMP occurs. However, the '405 appHcation does not disclose that if 
vendor information was obtained from a device^ that support information is obtained from a 
second memory. In this regard, AppUcants note that the Office Action refers to paragraphs 
[0344] and [0345] as disclosing this step, implying that the support information is the 
configuration information disclosed in step 610 of Fig, 6. However, Applicants note that the 
condition for performing in '405 Figure 6 is that the data gathering element is not configured, 
not if the vendor information was obtained, as is required by Claim 1. In this regard, 
Apphcants note that the Office Action implies that the DGE being not configured "is 
essentially the same as 'if the vendor information was obtained' since if the vendor 

* See '405 application, paragraph [0339]. 
^ Id. at paragraph [0340]. Emphasis added. 
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information is obtained, the data gathering information would be inherently no[t] 
configured."^ However, it is unclear to Applicants how the *405 application discloses that a 
DGE must not be configured if vendor information was obtained. Figure 6 of the '405 
application merely discloses that the DGE must be configured before monitoring can occur. 
Even if obtaining vendor information is part of the '405 configuration process, which has not 
been shown, the '405 application does not disclose that if vendor information was obtained, 
the obtaining and storing steps recited in Claim 1 are then performed. 

Moreover, Applicants respectfiiUy submit that the '405 application fails to disclose 
that, if the vendor information was obtained, storing the vendor information and the 
respective support information in each protocol object (i.e., including necessarily those not 
associated with the currently selected communication protocol), as recited in Claim 1 . The 
'405 application does not even disclose that the vendor information and the support 
information are stored in a protocol object . In this regard, it is unclear to Applicants how the 
'405 application discloses a protocol object associated with a respective communication 
protocol, as recited in Claim 1 . The '405 application discloses that the vendor and model 
information may be stored in a target device database record , and that configuration 
information is downloaded to a DGE. However, the '405 application does not disclose that 
both the vendor information and the support information are stored in each protocol object of 
the plurality of protocol objects, if the vendor information was obtained from the device, as 
recited in Claim 1. 

Further, Applicants respectfully submit that the '405 application fails to disclose that 
if the vendor information was not obtained firom the device, repeating the preceding steps 
until the vendor information is obtained or until each communication protocol of the 
respective communication protocols has been selected, as recited in Claim 1 . In this regard, 

^ Pages 10-11 of Office Action. 
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Applicants note that the Office Action refers to paragraph [0340] of the '405 appUcation as 
disclosing in this step. Paragraph [0340] refers to an auto-discovery mechanism for SNMP, 
but does not explicitly state that if vendor information is not obtained from a device that a 
selecting step, a retrieving step, an accessing step, a determining step, and conditionally, an 
obtaining and storing step are performed, as required by Claim 1 . In this regard. Applicants 
note that the *405 application does not disclose repeating the step of selecting a protocol. The 
'405 application only discloses SNMP. Further, the '405 application does not teach or 
suggest that a new communication protocol should be selected if vendor information was not 
obtained, as recited in Claim 1. 

In this regard, Applicants note that the Advisory Action dated September 14, 2006, 
states that because the '405 application discloses a variety of port monitors,"^ it is "inherent 
that if the vendor information were not obtained using SNMP, it would be obtained using any 
number of the various protocols taught by Aggarwal^^ However, Applicants respectftilly 
submit that the Office is vastly exaggerating the importance that the '405 places on vendor 
information. The Office provides no evidence that the '405 system will select another 
protocol and access the device using the selected protocol to attempt to obtain the vendor 
information if the vendor information was not obtained using another protocol. The '405 
patent simply does not teach or suggest this limitation merely by mentioning port monitors 
involving protocols other than SNMP. Further, Applicants submit that such a step is not 
necessarily present in the '405 disclosure since the '405 application does not teach or suggest 
that repeated efforts will be made to obtain the vendor information by accessing the 
monitored device. 

The '248 patent is directed to a system for selecting a network management protocol 
by setting a protocol handler index based on the newly selected protocol. In particular, the 

^ '405 application, paragraphs 68-78. 

^ Advisory Action dated September 14, 2006, page 3. 
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'248 patent discloses the step of receiving a request at a communication device to change the 
presently selected network management communication protocol to a new network 
management communication protocol selected from among the plurality of network 
management communication protocols residing in the communication device.^ However, 
Applicants respectfully submit that the '248 patent fails to disclose the two conditional 
statements recited in Claim 1. Li particular, the '248 patent fails to disclose a protocol object 
or the storing of vendor and support information in each protocol object associated with a 
plurality of the communication protocols, as recited in Claim 1 . Moreover, Applicants note 
that the '248 patent does teach or suggest that a new communication protocol should be 
selected if vendor information was not obtained from a device, as recited in Claim 1 . 

Thus, no matter how the teachings of the '405 application and the '248 patent are 
combined, the combination does not teach or suggest that (1) if the vendor information was 
obtained from a device , obtaining, from a second memory, support information for extracting 
the status information using each of the respective communication protocols, and storing the 
vendor information and their respective support information in each protocol object of the 
plurality of protocol objects; and (2) if the vendor information was not obtained from the 
device, repeating the preceding steps until the vendor information is obtained or until each 
communication protocol of the respective communication protocols has been selected, as 
recited in Claim 1. Moreover, the '248 patent discloses the use of port 134, while the '405 
application discloses the use of SNMP, which uses port 161. Accordingly, Applicants 
respectfully submit that a prima facie case of obviousness has not been established and the 
rejection of Claim 1 (and dependent Claims 2-10) should be withdrawn. 

Further, Applicants respectfully submit that there is no technological motivation for 
combining the teachings of the '405 application and the '248 patent. In particular, Applicants 



^ '248 patent, column 7, lines 5-10. 
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note that Claim 1 requires that if vendor information is not obtained from a monitored device, 
several steps are repeated, including the step of selecting a communication protocol among a 
plurality of communication protocols until the vendor information is obtained or until each 
communication protocol has been selected. However, nothing in the '405 application or the 
'248 patents teaches or suggests such an iterative process to obtain the vendor information of 
a monitored device using the plurality of communication protocols. The *248 patent 
discloses that a protocol is changed based on a request, but does not teach or suggest that a 
communication protocol should be changed based on whether particular information is 
obtained from a particular device, as recited in Claim 1 . Moreover, the *405 application does 
not teach or suggest changing communication protocols in order to obtain vendor information 
from a monitoring device, as recited in Claim 1. The '248 patent discloses the use of port 
134, while the '405 application discloses the use of SNMP, which uses port 161. 
Accordingly, for these additional reasons. Applicants respectfully submit that prima facie 
case of obviousness has not been established and that the rejection of Claim 1 (and dependent 
Claims 2-10) should be withdrawn. 

Independent Claims 1 1 and 21 recite limitations analogous to the limitations recited in 
Claim 1. Accordingly, for the reasons stated above for the patentability of Claim 1, 
Applicants respectfully submit that a prima facie case of obviousness has not been 
established and that the rejections of Claims 1 1 and 21 (and all associated dependent claims) 
should be withdrawn. 
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VIII. CONCLUSION 

For the foregoing reasons. Applicant respectfully submits that each of claims 1-30 

patentably distinguishes over the combined teachings of the '405 application and the '248 

patent. Therefore, the outstanding rejections must be REVERSED. 

Respectfully submitted, 

OBLON, SPIVAK, McCLELLAND, 
MAIER & NEUSTADT, P.C. 
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CLAIMS APPENDIX 

1. (Rejected) A method of initializing a plurality of protocol objects associated with 
respective communication protocols used to extract status information related to a monitored 
device communicatively coupled to a network, comprising: 

selecting a commimication protocol among the respective commimication protocols; 

retrieving, from a first memory, information for accessing the device using the 
selected communication protocol; 

accessing the device using the selected communication protocol and the information 
retrieved from the first memory to attempt to obtain vendor information related to the device; 

determining whether the vendor information was obtained from the device; 

if the vendor information was obtained from the device, (1) obtaining, from a second 
memory, support information for extracting the status information using each of the 
respective communication protocols, and (2) storing the vendor information and the 
respective support information in each protocol object of the plurality of protocol objects; and 

if the vendor information was not obtained from the device, repeating the preceding 
steps until the vendor information is obtained or imtil each communication protocol of the 
respective communication protocols has been selected. 

2. (Rejected) The method of claim 1, further comprising: 

accessing the device using the selected communication protocol and the information 
retrieved from the first memory to attempt to obtain model information related to the device. 

3. (Rejected) The method of claim 1, wherein the selecting step comprises: 
selecting the communication protocol among SNMP, HTTP, and FTP. 
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4. (Rejected) The method of claim 1, wherein the retrieving step comprises: 
retrieving an IP address of the device, wherein the device is one of a copier, a scanner, 

a printer, a facsimile machine, an appliance, and a metering system. 

5. (Rejected) The method of claim 1, wherein the selecting step comprises selecting 
FTP, and the retrieving step comprises retrieving at least one of a usemame and a password 
for accessing the device using FTP. 

6. (Rejected) The method of claim 1, wherein the selecting step comprises selecting 
SNMP, and the retrieving step comprises retrieving at least one of a community name and a 
password for accessing the device using SNMP. 

7. (Rejected) The method of claim 1, wherein storing the vendor information 
comprises storing the vendor information in protocol-dependent data structure associated 
with each protocol object. 

8. (Rejected) The method of claim 1, wherein the retrieving step comprises: 
retrieving at least one of a web page address, a keyword, and a relative location for 

accessing the device using HTTP. 

9. (Rejected) The method of claim 1, wherein the accessing step comprises: 
transmitting, to the device, the information to access the device using the selected 

communication protocol. 

10. (Rejected) The method of claim 9, wherein the accessing step comprises: 
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receiving, by the device, the transmitted information; and 

processing, by the device, the received information. 

11. (Rejected) A system for initializing a plurality of protocol objects associated with 
respective communication protocols used to extract status information related to a monitored 
device commxmicatively coupled to a network, comprising: 

means for selecting a communication protocol among the respective communication 
protocols; 

means for retrieving, from a first memory, information for accessing the device using 
the selected communication protocol; 

means for accessing the device using the selected communication protocol and the 
information retrieved from the first memory to attempt to obtain vendor information related 
to the device; 

means for determining whether the vendor information was obtained from the device; 

means for obtaining, from a second memory, support information for extracting the 
status information using each of the respective communication protocols, if the means for 
determining determines that the vendor information was obtained from the device; and 

means for storing the vendor information and the respective support information in 
each protocol object of the plurality of protocol objects, if the means for determining 
determines that the vendor information was obtained from the device. 

12. (Rejected) The system of claim 11, fiirther comprising: 

means for accessing the device using the selected communication protocol and the 
information retrieved from the first memory to attempt to obtain model information related to 
the device. 
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13. (Rejected) The system of claim 11, wherein the means for selecting comprises: 
means for selecting the communication protocol among SNMP, HTTP, and FTP. 

14. (Rejected) The system of claim 11, wherein the means for retrieving comprises: 
means for retrieving an IP address of the device, wherein the device is one of a copier, 

a scanner, a printer, a facsimile machine, an appliance, and a metering system. 

15. (Rejected) The system of claim 11, wherein the means for selecting comprises 
means for selecting FTP, and the means for retrieving comprises means for retrieving at least 
one of a usemame and a password for accessing the device using FTP. 

16. (Rejected) The system of claim 11, wherein the means for selecting comprises 
means for selecting SNMP, and the means for retrieving step comprises means for retrieving 
at least one of a community name and a password for accessing the device using SNMP. 

17. (Rejected) The system of claim 1 1, wherein the means for storing the vendor 
information comprises means for storing the vendor information in protocol-dependent data 
structure associated with each protocol object. 

18. (Rejected) The system of claim 1 1, wherein the means for retrieving comprises: 
means for retrieving at least one of a web page address, a keyword, and a relative 

location for accessing the device using HTTP. 

19. (Rejected) The system of claim 11, wherein the means for accessing comprises: 
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means for transmitting, to the device, the information to access the device using the 

selected communication protocol. 

20. (Rejected) The system of claim 19, wherein the means for accessing comprises: 
means for receiving, by the device, the transmitted information; and 

means for processing, by the device, the received information. 

21 . (Rejected) A computer program product having a computer usable medium for 
initializing a plurality of protocol objects associated with respective communication protocols 
used to extract status information related to a monitored device communicatively coupled to a 
network, comprising: 

instructions for selecting a communication protocol among the respective 
communication protocols; 

instructions for retrieving, from a first memory, information for accessing the device 
using the selected communication protocol; 

instructions for accessing the device using the selected communication protocol and 
the information retrieved from the first memory to attempt to obtain vendor information 
related to the device; 

instructions for determining whether the vendor information was obtained from the 

device; 

if the vendor information was obtained from the device, (1) instructions for obtaining, 
from a second memory, support information for extracting the status information using each 
of the respective communication protocols, and (2) instructions for storing the vendor 
information and the respective support information in each protocol object of the plurality of 
protocol objects; and 



17 



Application No. 10/764,582 

Reply to Final Rejection of May 23, 2006 

if the vendor information was not obtained from the device, instructions for repeating 
the preceding instructions until the vendor information is obtained or until each 
communication protocol of the respective communication protocols has been selected. 

22. (Rejected) The computer program product of claim 21, further comprising: 
instructions for accessing the device using the selected communication protocol and 

the information retrieved from the first memory to attempt to obtain model information 
related to the device. 

23. (Rejected) The computer program product of claim 21, wherein the instructions 
for selecting comprise: 

instructions for selecting the communication protocol among SNMP, HTTP, and FTP. 

24. (Rejected) The computer program product of claim 21, wherein the instructions 
for retrieving comprise: 

instructions for retrieving an IP address of the device, wherein the device is one of a 
copier, a scanner, a printer, a facsimile machine, an appliance, and a metering system. 

25. (Rejected) The computer program product of claim 21, wherein the instructions 
for selecting comprise instructions for selecting FTP, and the instructions for retrieving 
comprise instructions for retrieving at least one of a usemame and a password for accessing 
the device using FTP. 

26. (Rejected) The computer program product of claim 21, wherein the instructions 
for selecting comprise selecting SNMP, and the instructions for retrieving comprise 
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instructions for retrieving at least one of a community name and a password for accessing the 
device using SNMP. 

27. (Rejected) The computer program product of claim 21, wherein the instructions 
for storing the vendor information comprise instructions for storing the vendor information in 
protocol-dependent data structure associated with each protocol object, 

28. (Rejected) The computer program product of claim 21, wherein the instructions 
for retrieving comprise: 

instructions for retrieving at least one of a web page address, a keyword, and a 
relative location for accessing the device using HTTP. 

29. (Rejected) The computer program product of claim 21, wherein the instructions 
for accessing comprise: 

instructions for transmitting, to the device, the information to access the device using 
the selected communication protocol. 

30. (Rejected) The computer program product of claim 29, wherein the instructions 
for accessing comprise: 

instructions for receiving, by the device, the transmitted information; and 
instructions for processing, by the device, the received information. 



19 



application No. 10/764,582 

Reply to Final Rejection of May 23, 2006 



EVIDENCE APPENDIX 
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